IBIS Macromodel Task Group Meeting date: 12 May 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC * David Banas Marc Kowalski Ericsson: Anders Ekholm IBM Steve Parker Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Nicholas Tzou Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: Randy Wolff * Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: * Alfred Chong (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Mike LaBonte unable to attend, Curtis Clark to take the minutes. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad, send email to IBIS reflector with ATM Task Group's recommendation to approve the PAM4 BIRD. - Done. - Arpad, Submit [Define Package Model] BIRD to IBIS Open Forum. - Done, BIRD176, would like to discuss what happened. - Arpad to review IBIS specification for min max issues. - In progress. ------------- New Discussion: - Arpad: We have several topics for discussion. I don't care about the order. - I would like to explain why a different version was submitted as BIRD176. - Walter has done work on the global ground problem. - Michael M., do you have anything on directionality? - Michael M: A little bit. - We had a good discussion amongst some, including Bob Miller. - He had some questions about how the BIRD was put together. - He is not here today though. BIRD 176 - Power Pin Package Modeling - Arpad: I would like to describe what happened to BIRD 176. - In last week's meeting we reviewed draft 3. - We discussed it and decided it was ready for the Open Forum. - After that meeting I created a draft 4. - Draft 3 was well written, but I had issues with it and was still listed as an author at that time. - Based on internal discussions with Mentor colleagues. - Also, my own personal opinion that draft 3 was not acceptable. - Main issues for me: - Language that made some of the new capabilities optional. - This would have required GUI development from developers. - Would create confusion for users, especially with legacy models. - After I created draft four, we had a meeting amongst the authors. - Bob, Radek, Randy, and myself. - Used the editorial meeting time slot on Friday to review draft 4. - As a result of that, modified the document to create draft 5. - Submitted that to the Open Forum to become BIRD 176. - The authors considered going back to the ATM Task Group first. - In the interest of time, decided to submit it to the Open Forum. - Bringing draft back to this group for retroactive approval. - We have options moving forward if this group disapproves. - Vote it down in the Open Forum. - Create a new version, etc. - Even after draft 5 was prepared, some Mentor colleagues wanted Mentor to be removed from the authors. - I am no longer listed as an author. - Not for technical reasons. - Mentor may choose not to implement support for the current BIRD. - Would seem odd not to support a BIRD if listed as an author. - Arpad: - Bob: I joined as an author. It was a good BIRD. - Great editorial improvements were made over last week's draft. - However, I now have second thoughts. - What was stripped out in terms of "optional" language is what made it acceptable to me. - As now written, it is technically questionable: - Implied shorts may or may not exist. May not be the best solution. - Radek: The BIRD was discussed with great help from Bob. - I joined the discussion to close ambiguities. - I think the BIRD, as submitted, is not necessarily as questionable as Bob suggests. - It is trying to specify something previously undefined. - Either we go the direction of saying every pin must be in [Pin Numbers] or [Merged Pins], or we need the language we have now. - Bob: What's proposed applies to all legacy versions. - It deprecates existing tool flows. - Radek: It is not retroactive to all older versions. - Bob: That's how you interpret it. - Implied pins will apply to all versions for the same reason. - Radek: I still think Arpad should be in [as an author]. - It's his and Mentor's decision. - Bob: I have a proposal I think will resolve everything. - [on page 5 of the BIRD] - Rather than "...the following rules apply to..." - Change to "...the following rules are suggested for power and ground pins..." - This would cover Mentor's concerns and make me happy. - Would avoid locking ourselves into something technically invalid. - Since it applies to tools and not content of the specification, it could be made as an editorial change. - Arpad: Please refrain from suggesting that it will resolve Mentor's concerns. - I think making it an option will create more concern at Mentor. - Tool might have to implement a GUI for choosing options. - It will make it even more expensive for tools to implement this BIRD. - Bob: Add language like, "for all tools this suggestion provides a path..." - Most tools will just decide to only comply with this suggestion. - We can suggest how to process unspecified information. - Arpad: I was an author up to the end. I wrote most of the BIRD. - The concern I have about making it optional is that we specify no default. - If we don't, then the choice must be made by the user. - If there is a choice, there will be questions. - We have all the legacy models out there. - Now we will present a new choice to the user and model maker. - Is that new choice going to be useful for existing models, or just cause confusion and trouble? - The new choice may give worse results if the model wasn't written that way. - That's why I prefer the no choice rule. - Bob: I understand, but a technically invalid choice is worse than leaving options open. - Most EDA vendors won't expend the energy to support all the choices. - Choices take time to implement anyway. - You mentioned defaults. We could add "suggested as the default choice..." - Then it doesn't undermine existing tools. - Deprecating most tool flows anyway, because this applies retro-actively to older models. - Arpad: You mentioned that this would invalidate a lot of existing models. - We discussed that in our meeting. - There aren't that many models that use [Pin Mapping]. - This rule only applies to them. - If the [Pin Numbers] lists all the [Pins], then this won't be an issue. - Randy mentioned the spatial resolution of the bedspring models. - If he wants to make more accurate models he can control the groups of pins that are shorted. - It is true that the resolution of the bedspring model might be reduced by the shorts that this BIRD implies. - RLC package models aren't that accurate anyway. - May not be a perfect solution, but RLC matrices are imperfect to start. - Bedspring issue may not reduce overall accuracy anyway, given RLC. - My impression from the discussion was that Randy was satisfied with this as an interim solution. - When the accuracy of these is no longer sufficient, we should have the new interconnect proposal by then. - We should try to keep this interim solution as simple as possible. - Bob: I think my suggestion is a better solution. - Your argument is that this is already a defective solution, so we can put another defective solution in IBIS. - I would argue that, even if Randy wants it, a defective solution is worse than no solution. - Arpad: My understanding is that Randy thinks it works as an interim solution. - Bob: He was willing to accept "suggested" and not the mandated solution. - EDA vendors can adopt the "suggested" language and not corrupt IBIS. - Otherwise we may be mandating something that may not be technically valid. - IBIS is a data spec. not an EDA tool spec. - Randy can choose to group pins as you suggested. That explicit merging is okay if he chooses to do it. - But implicit merging could still exist with [Merged Pins] and is a problem. - Radek: Unless there is a clear requirement that any [Pin Mapping] pin that is not in [Pin Numbers] must be in [Merged Pins]. - That's one way of removing ambiguity. - I agree with Arpad's statement that if we just change it to "suggested" behavior then no default is specified. - Last week's version did have a default behavior. - The optional nature was stressed by the statement that the tool, "may provide the option for the user to select." - There were no ambiguities. - Arpad: I'd like to ask others listening, what should be our next step? - We could recommend voting the current BIRD down. - We could submit a second BIRD. - What should we do in the upcoming weeks? - It was submitted to be available for the next Open Forum meeting. - Walter: I make a motion that this group recommends that the Open Forum table this BIRD in the Open Forum until ATM comes up with a recommendation. - Bob: Clarification, the motion to table would be made at Open Forum, not here. - Walter: That's right, it's not to table it here. - Though I would table it here for now. - I recommend that this group recommends to the Open Forum that this BIRD be tabled in the Open Forum meetings. - Radek: I don't think that's a good direction. - We are here to provide an advisory function. - Open Forum may request ATM to provide input. - Open Forum can make decisions regardless. - Open Forum can table, reject, etc., on its own. - Arpad: We have a motion, do we have a second? - Do we need to restate the motion again? - Michael M: It would help. - Walter: I move that IBIS ATM recommends to the Open Forum that any further discussion on BIRD176 be tabled in the Open Forum meeting. - Arpad: Seconds? - Curtis: I second. - Arpad: Anyone opposed to tabling this BIRD in the Open Forum. - Bob: I oppose. - That motion can be made at the Open Forum meeting. - We can continue discussing this at the ATM. - Michael M: Was your intent to recommend to the Open Forum that this be tabled? - Walter: Correct. - Arpad: Do we need a roll call vote? Not used to having objections. - Michael M: Unless the motion is amended and seconded or withdrawn. - Hence my clarification regarding the recommendation. - Bob, you don't object to a recommendation from this body to the Open Forum? - Bob: This resolution should not override the fact that we might reach a consensus anyway. - Not a meaningful motion. - Walter: I withdraw the motion. - I think we've invested too much time on this in this meeting. - The authors of this BIRD should get together and come up with something they all can agree to in a clear manner. - The whole purpose of this BIRD was to get into IBIS 6.1. - That clearly isn't going to happen in the current state. - I'm now making a motion that we table this BIRD in this meeting. - Michael M: I'll second. - Arpad: Anyone opposed to tabling the discussion on this BIRD until the authors come to some decisions? - Bob: I'll oppose the motion so we have to have a vote. - Vote to table: - 4 yes (ANSYS, Mentor, Intel, SiSoft) - 2 no (Teraspeed, Micron) - 1 abstention (Keysight) - The BIRD is tabled. - Arpad: Okay, Walter. Problems with Global Ground in IBIS: - Walter: I have ten minutes to solve the problem of global ground. - We've been fighting this issue in the interconnect meetings. - We need to cleanup IBIS 6.0. - - We've decided in interconnect meetings, as long as global ground doesn't show up in your interconnect then everything is okay. - Global ground is implied in the schematic: - Simulators don't keep track of the potential differences directly. - They keep track of single values representing node voltages. - Each of those single values is relative to simulator global ground. - As long as no current goes there it's okay. Packaging modeling is good. - Problem occurs when you look into IBIS 6.0. - - What does that little ground symbol mean? - "GND" is all over the place. - Even the words "global ground" are found here and there. - How do we fix these? - Terminator model diagram is the biggest headache, but easiest to solve. - This ground symbol was an editorial problem introduced going from 5.0 to 5.1. - The original drawing had "GND" not some global ground symbol. - Problem is that to some of us "GND" looks like it might mean node 0. - IBIS-ISS, for example has GND meaning global ground since it is inherited from HSPICE syntax. - But that was not the original intent of all the "GND" references in IBIS. - I think GND was meant to imply the signal name GND in the [Pin] section. - I think even in the original diagram GND was wrong. - Arpad: I think you're correct that they are tied together if it's the same voltage, but it's drawn that way for something like ECL where those voltages aren't the same. - Bob: You had it right that that symbol should just be local ground reference. - Walter: Yes, but what would local ground reference be other than [GND Clamp reference] or [Pulldown reference]? - There is no other reference we can define in IBIS. - I sent out an IBIS 6.0 with a bunch of changes. - Wherever we have GND it is confusing. - If we just change those to VSS it clarifies things tremendously. - We should avoid using "GND" unless it's in a space where it is explicitly defined (e.g. as in [Model] name). - I ask people to just go through all those changes. - If we just make it clear that "GND" is local ground reference which is in turn defined as connected to pins with a specific signal name that are model ground. ([GND Clamp reference] or [Pulldown reference]) - Could go through and make the changes I've recommended in this document and review them carefully. - Any questions? - Bob: We have to go through this carefully. - Pages 53, 54, 55, we have to be very careful. That was intended to be a local ground reference or [Pulldown reference]. - Radek: Yes, we have to be careful. - I think there is nothing wrong with "GND" if it is known that it is not assumed to be global ground. That can be explained. - To be free of global ground is relatively easy. - Local ground still exists for C_comp. We can't avoid it unless we recommend the other C_comp_xxx. - Making the statement that GND and [Pulldown reference] are the same invalidates keywords. We don't want to make them identical when [GND Clamp reference] or [Pulldown reference] were able to be different. - Walter: Yes, that's the hardest one. - If you have distinct [GND Clamp reference] and [Pulldown reference] terminals then we could define a precedence ([GND Clamp reference] first or vice versa). - That's the only one where the local reference is not obvious. - Radek: That's not the current interpretation of the spec. - You can have a local ground reference say 1V (need not be zero). - You can have a Pulldown ref at 2V (1V over local ground). - You can have a ground clamp ref .5V (.5V over local ground). - Hard to get out of that. - Walter: Your statement is confusing me. - You're saying you can have a model with 3 terminals (pd_ref, gc_ref, and local ground reference). What we said in packaging is that we can only use as reference voltages signal names that are pins of [Model] GND or POWER. - That means in the [Pin] list there has to be a signal name that corresponds to that particular local ground terminal. - How do we associate that particular signal name in the [Pin] list with that particular local ground terminal in the [Model]? - Radek: I don't know, but we have to handle what we have in the current spec. - Walter: What do we have in the current spec with C_comp? - In the current spec it's hooked up to "GND." - Radek: Yes. - Walter: GND is not local ground, GND is the signal name. - Radek: Or the model name. - Walter: Ah, but in other places we use VCC and VDD not POWER for the node. - We imply in many places that VDD is the component [Pin] signal name. - If we simply make the assumption that "GND" is just one of the signal names in the [Pin] list that is on model GND. - Radek: I would like that solution, but we still have the existing interpretation to address. - Walter: Show me where there is an interpretation that C_comp goes to a local ground that is neither [GND Clamp reference] or [Pulldown reference]. - Radek: If we have a picture anywhere that includes Pulldown, pullup and C_comp then the C_comp is clearly not connected to [GND Clamp reference] or [Pulldown reference] but to the GND node. - Walter: Yes, GND node, is it the signal name or the HSPICE interpretation? - Radek: I'm not talking about the global ground interpretation. - I'm talking about GND being a different node voltage with respect to [GND Clamp reference] or [Pulldown reference]. - Walter: Here's a picture (ISSO PD picture). - Pulldown goes to GND or [Pulldown Reference]. - [Pulldown Reference] here is a voltage level. - That's when it's a DC voltage level, but when it gets hooked up to the rail voltage it's the local ground. - Radek: If [Pulldown Reference] is not zero, then you have a difference between that and GND voltage level. That will affect the simulation. - Walter: No, when [Pulldown Reference] is something other than zero, it's saying the rail is something other than zero. - When someone says [Pulldown Reference] is .1V that means the rail terminal is .1V, so the local ground is .1V. - The [Pulldown Reference] is the voltage put on the rail when the IV curves are measured. - Bob: Yes, but it's relative to zero volts. - .1 is relative to zero and therefore zero is defined as the meaning of GND. - Walter: No, zero is the chassis ground at this point. - We have this fundamental problem with the reality of the silicon and the way some people are interpreting the IBIS text. - There's no reality to the statement that when you're doing a measurement of the I/V curves. - If you say the [Pulldown Reference] is 0.1V, that means the rail on the silicon is at .1V. - That .1V isn't relative to any other node in the silicon. It's relative to some test fixture you're measuring from... - Arpad: We're 15 minutes over time. Now would be a sufficient place to stop. - Walter made a point of describing his initial work here. - We need to dive in and review things. - For today that should be enough to introduce the problem. - Walter: This is excellent, thank you. - Bob: By the way, this is good work mostly. - Walter: We're having a debate, when you say [GND Clamp reference] is .1V, what does that mean? - Bob: It means how the model was extracted. - Walter: It doesn't say what the .1V is relative to. - Arpad: I would say it's relative to the VRM module. - Like I said, I think we should stop here. - Walter: I think it's reference to chassis ground. - Really important, there's no capacitance to chassis ground. - The capacitance is to the local rail ground, which is .1V. - The capacitor itself is in the buffer. How could it have a capacitance to the chassis? - Doesn't it make sense that C_comp, that capacitor in the buffer, is a piece of metal that has capacitance to some copper of local ground and not capacitance to the chassis? - Arpad: Alright, I highly recommend that we stop for now and continue in email or next week. - Thanks for joining everybody. ------------- Next meeting: 19 May 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives